The dedicated x86-pytorch-build-runner fleet is defined in
DLContainersInfraCDK mainline (commit 85a06e065, rebalanced by
f4bcbc9c on 2026-06-30) - identical hardware to x86-vllm-build-runner
and x86-sglang-build-runner, but reserved for pytorch.

Route all pytorch builds (both CPU and GPU) to the dedicated fleet
unconditionally, matching the vllm.pipeline.yml and sglang.pipeline.yml
pattern. This replaces the temporary conditional that routed GPU builds
to x86-vllm-build-runner as a stopgap.

Cache locality on a dedicated fleet is expected to fix the wheel-export
OOM: BuildKit finds the primary build's flash-attn + TE layers still
cached on the same host, so the wheel-export re-run reduces to a
COPY --from=<cached-layer> instead of a concurrent recompile.

- pytorch.pipeline.yml: unconditional fleet:x86-pytorch-build-runner
- ci-architecture.md: document the new fleet row

PR-6365 ECR vulnerability scan flagged 2 HIGH CVEs on 2.13 CPU
images (also on SageMaker CPU variant). Both are unbounded-memory /
catastrophic-backtracking bugs in soupsieve's CSS selector parser,
fixed upstream in 2.8.4.

soupsieve is transitive via beautifulsoup4 -> python-fasthtml ->
fastai. Add an explicit direct pin `soupsieve>=2.8.4` to both cpu
and cuda pyproject.toml (following prior transitive-CVE bump
convention: msgpack, tornado, cryptography, aiohttp), regenerate
uv.lock via `uv lock`.

CVEs cleared:
- GHSA-2wc2-fm75-p42x (unbounded memory on large selector lists)
- GHSA-836r-79rf-4m37 (regex catastrophic backtracking on attribute selectors)

Upstream fix pin: soupsieve>=2.8.4

The wheel-cache upload path re-runs `docker buildx build --target
wheel-export` to extract compiled wheels from the wheel-export stage.
Because that re-invocation passed NO --build-arg while the primary
build passes ~15 of them, BuildKit computed a different cache key for
every stage and had to recompile flash-attn + TE from source
concurrently, OOM-killing the CodeBuild runner (exit 137 at
upload_wheels.sh:45).

Forward the same --build-args the primary build uses (read from
EXTRA_BUILD_ARGS env var, the space-separated list of arg names the
build-image action already computes via resolve_build_args.py). The
wheel-export stage now hits BuildKit's local cache for every prior
stage and reduces to a COPY --from=<cached-layer>, avoiding the
recompile entirely.

Reverts commit 2705344. That change forwarded primary-build --build-args
to the wheel-export re-invocation to make BuildKit cache-hit and avoid
recompiling flash-attn + TE.

No longer needed: the x86-pytorch-build-runner fleet has been bumped from
m6a.8xlarge (128 GB) to m6a.12xlarge (192 GB) via DLContainersInfraCDK CR
CR-288126860. The runner now has enough memory headroom to complete the
cold-cache wheel-export recompile without OOM.

Reverting keeps upload_wheels.sh in its upstream shape for other
frameworks that share the pattern (though currently only pytorch_runtime
uses this exact copy).

Starting with EFA 1.48, the installer auto-detects NGC containers via
/opt/nvidia/nvidia_entrypoint.sh (present in nvidia/cuda:*-amzn2023 base
images) and skips installing the AL2023 libnccl-ofi RPM. This left the
pytorch runtime image without libnccl-net.so, breaking every unit /
sanity / single-gpu / efa test that asserts the OFI plugin is present.

The sibling scripts/docker/common/install_efa_amzn2023.sh already has
this fix (lines 37-48); mirror the version-gated --disable-ngc flag here
so aws-ofi-nccl installs regardless of the base-image NGC detection.

Only affects pytorch - sglang, vllm, and vllm-omni use the common
installer via their own paths.

Both fetch_wheels.sh and upload_wheels.sh keyed the S3 wheel cache
by ${PKG}/cu${MAJOR}${MINOR}/${FNAME}, omitting the torch version the
wheel was compiled against. Since pytorch 2.12 and 2.13 both pin
flash_attn 2.8.3 + cuda 13.0.2, the 2.13 build fetched 2.12's cached
wheel and loaded it into torch 2.13 - producing an undefined symbol
at import (c10::impl::cow::materialize_cow_storage, removed in
torch 2.13).

Key by torch major.minor as well, so cross-torch-version cache reuse
is impossible by construction. transformer-engine-torch would hit the
same bug at the next torch bump.

Note: stale cu130/torch212 wheels remain in s3://dlc-cicd-wheels/
under the old key format. They're now orphaned and unreferenced -
safe to delete via a separate S3 cleanup, or leave as is.

TE 2.16.1 calls cublasLtGroupedMatrixLayoutInit_internal which requires
libcublasLt.so.13.3, but our runtime base image (nvidia/cuda:13.0.2-
runtime-amzn2023) ships an older cuBLASLt. The build succeeds against
devel headers but fails to load at runtime with:

  ImportError: /path/libtransformer_engine.so: undefined symbol
  cublasLtGroupedMatrixLayoutInit_internal, version libcublasLt.so.13

TE 2.13.0 predates the cuBLAS 13.3 dependency (grouped GEMM with
on-device group sizes landed in TE 2.14 via NVIDIA/TransformerEngine
#2748) and is torch-2.13 compatible. Bump base CUDA to 13.3.x-amzn2023
in a follow-up once that image is available on Docker Hub.